Subject: APPN arch. items 8264, 8265, and 8266

From: [email-masked]
Date: Thu, 13 Jul 95 14:20:24 EDT

Hi Mike,

Long time no hear or see.
I imbedded my responses in your note, prefixed by TRH.

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Here are DCL's comments on the proposed architecture changes 8264, 8265 and
8266.  Sorry they are late, but since the updates are still being discussed
we thought we would submit them.

Mike Evans
Data Connection Ltd (DCL)
+44 181 366 1177

 ----------------------------------------------------------------------------

arch8264
 --------

No issues.

arch8265
 --------

We have a number of concerns with the proposed solution.

1)  The solution does not deal at all with the case when one of the
    duplicate nodes is specified by an End Node in origin or destination
    TG vectors.  For example, this would happen if the End Node had a
    connection network configured with the same name as a Network Node,
    and could result in the NN calculating an invalid route.

TRH:  the solution described in 8265 detects the problem immediately when
TRH:  the duplicate node attempts to "hook in" to the network.  That's pretty
TRH:  darn quick.  I don't think it's necessary to make this very simple
TRH:  function more complex by adding extra checking that provides little
TRH:  benefit.  It's true that if the operator decides the problem lies
TRH:  with the VRN, and its name has to change, then the operator has to
TRH:  reconfigure any ENs that are using the old CP name.  But that's for the
TRH:  operator to decide, not for us.

TRH:  Am I missing something obvious, here, Mike?

2)  If the duplicate VRN is caused by a local configuration change (ie.
    a DEFINE_CN command), TDUs with the duplicate VRN information are still
    sent into the network.

TRH:  No.  If the NN has the function described in 8265, TDUs are not issued.
TRH:  Because when TRS first learns about the VRN, it'll discover that a
TRH:  node record already exists with that name, that the node record
TRH:  represents a real NN, and it'll issue an Alert, basically telling the
TRH:  operator that he's dopey.

3)  The solution requires operator intervention to ultimately clear the
    problem.

TRH:  It requires operator intervention because it is an operator error that
TRH:  is causing this problem.  The operator needs to fix what he/she
TRH:  did by renaming one of the duplicate nodes.  I know you don't agree
TRH:  that this is an error, but I really can't see a good reason for
TRH:  anyone to give two different nodes the same CP name, unless by mistake.
TRH:  In fact, our architecture does state that LU names and CP names must
TRH:  all be unique.  It's true that dumb rules are made to be broken, but
TRH:  I don't think this rule is dumb, even when one of the nodes is a VRN.

Both 1 and 2 are relatively easy to fix (but add special case logic to
fairly critical codepaths).  3 is inherent in this approach to solving the
problem.

An alternative approach is to just treat the NN and VRN as separate
resources
 - that is, create two node records in the network topology database, and use
the VRN indicator to distinguish between them.

This approach

 -  causes no network problems (since it is always clear which record a node
   descriptor or TG identifier refers to)

 -  doesn't require operator intervention

 -  handles the TG vector case as well.

TRH:  technically, this is a sound idea.  Why not be forgiving if an NN
TRH:  has the ability to be forgiving?  The problem with this solution is
TRH:  not technical, but pragmatic, because it would require every APPN
TRH:  NN box in the network to have this function.  Let me explain.

TRH:  All current APPN NN boxes that I know of will do the following when
TRH:  connecting to a network that has a VRN with the same CP name:

TRH:      - NN A will learn about VRN A in the topology exchange.
TRH:      - Because the information in VRN As record is not the same as
TRH:        what NN A has for its own record, NN A will think that someone
TRH:        out there is messing with its own information and will issue a
TRH:        new TDU replacing VRN A's information with NN A's information.
TRH:      - NN A will discard VRN A's record and NOT put it in the TDB.
TRH:      - NN A will mark all the TGs owned by VRN A inconsistent, and
TRH:        broadcast all these records in a TDU.
TRH:      - VRN A has just been taken out of the network.

TRH:  none of this is good.  It's downright nasty what current nodes will
TRH:  do to the poor VRN.  Even if the duplicate NN has the function you
TRH:  propose, any downlevel NNs will take the information they learn about
TRH:  this NN and overwrite over what was their VRN record, because they
TRH:  assume, because the names are the same, that this is just new
TRH:  information about that node.

TRH:  Now, imagine a network that has NNs with this new function and also has
TRH:  down-level NNs.  If an NN comes along that happens to have the same
TRH:  name as a VRN in the network, the up-level NNs will say 'No problem,
TRH:  everything's cool here.  I can handle this.  Aren't I smart?'  Meanwhile,
TRH:  the down-level NNs are busy hosing off what was left of the VRN in their
TRH:  TDBs.

TRH:  Only one NN in a network needs to have the function in 8265.  It just
TRH:  takes one to detect the problem, and Alert the operator to the CP name
TRH:  error.  The operator changes one of the names, the appropriate TDUs
TRH:  flow automatically, and the TDB is AOK again.

We would also argue that it is more in keeping with the original intent of
the architecture - ie. the TG identifier control vector, which includes the
VRN indicator, _identifies_ the TG.

The only difficult aspect of implementing this solution is supporting the
6611 APPN MIB (which doesn't use node type as an index into the topology
table, so needs some code to handle the rare case when there are two record
with the same name but different types).

TRH:  TRS doesn't use node type as an index into the TDB either.  It uses
TRH:  the node name, hence the problem when duplicates exist.

arch8266
 --------

It is not clear from the proposal which problem this proposal is attempting
to address.  We can see three possibilities.

1)   Centralising mode to COS mappings, so removing the burden of making
sure
     all EN mode to COS mappings are consistent.  If so, then a simple
     START_NODE parameter would suffice.

2)   Handling ENs with incorrect mode to COS mappings.  If this is the
problem
     then the solution to 1) is also sufficient (since by definition all the
     other ENs are consistent with the NN tables, so it doesn't matter who
     does the mapping).

3)   Handling a malicious or rogue EN (ie. a node trying to get better
     service for its sessions by specifying a higher priority COS than the
     session justifies).  If this is the problem, then the solution ought to
     be more secure than the one proposed, since the node can just send a
     different CP name (one that isn't restricted),

TRH: Yes, in some cases it's possible for some sneaky guy to somehow find
TRH: out what CP names a particular NN doesn't COS-restrict, and then use
TRH: one of these CP names as its own.  I'm not as convinced that this is a
TRH: grave concern.
TRH: Even if it were, there are a number of ways to get around this:
TRH:    - the operator can choose Add(ALL) with the COS-restrict command and
TRH:      now all ENs are restricted, regardless of their name.
TRH:    - the operator can choose Add(ALL) and then Delete for any ENs that
TRH:      he/she wants to allow to use their own COS.  Now, all ENs are
TRH:      restricted except for those few that were allowed.
TRH:    - for nonswitched links, it's common to configure the partner's CP
TRH:      name in the NN, anyway.  If it is configured the EN must use the
TRH:      configured name as its CP name, otherwise the link won't come up.

     or a different mode name

TRH:  You're right.  An EN can circumvent this restriction by using a mode
TRH:  name that maps to a high priority COS on the NN server.  But many
TRH:  applications do not allow users to override the mode name they use.  So
TRH:  the user has to use the mode associated with that application.  For
TRH:  those that allow an override, the user can change the mode to #INTER,
TRH:  thus giving them high priority sessions.  Is this a good enough
TRH:  restriction?  How easy is it for users to
TRH:  change the modes that their applications use?  I really don't know.  I'd
TRH:  like to hear from those who do know.  Any comments?

     (one that maps to a higher priority COS).  This lack of security is
     exactly the reason few implementations support the concept of
     unauthorised end nodes.

If the problem is 1 or 2, then I think inventing a new verb is currently
overkill.  If the problem is 3, then a more secure approach is required.

TRH:  the main concern here is 3), the lack of control net. mgrs. have over
TRH:  dictating session priority of their users, although your possibilities
TRH:  1) and 2) are also benefits that are obtained.

TRH:  good points raised, Mike.

---

From: Mike Evans <[email-masked]>
Date: Thu, 20 Jul 95 18:19:00 BST

Tim,

We still think proposals 8265 and 8266 are broken.  Our detailed responses 
are interspersed below.

Mike

> TRH:  Am I missing something obvious, here, Mike?

Sorry Tim, I hadn't made our concern clear.  The problem occurs when the 
connection network is not defined on any of the network nodes.  Since the 
VRN name is not included in any TDUs, it is never detected by your proposal. 
 If an end node then supplied the VRN name in a tail vector, it's NNS will 
calculate a bad route.

> TRH:  operator that he's dopey.

This is not true with the proposal as it stands, since the check is only 
performed when a TDU is _received_.  It is _not_ performed as a result of an 
internal resource update (eg. a TG_UPDATE signal).

>From a user's viewpoint, he is not giving two nodes the same name.  He is 
giving a connection network and a node the same name.  I've not found a 
reference anywhere in the APPN Architecture Reference saying that connection 
network names occupy the same name-space as CP and LU names.  Much of the 
product documentation I've looked at is similarly vague about this 
restriction.  We just don't agree that this is
a 'dumb' user error (we've even seen engineers at an Interop show configure 
a network this way).

> TRH:      - VRN A has just been taken out of the network.

No.  When a node connected to VRN A receives a TDU for the TG from VRN A to 
itself, it should then broadcast a TDU correcting that information (since it 
owns that TG).  A TDU war occurs (which may be detected if someone has 
implemented the TDU war architecture update, or may continue unabated).

> TRH:  the down-level NNs are busy hosing off what was left of the VRN in 
their

This is not strictly speaking true.  If the duplicate NN is down-level, a 
TDU war will occur.  If he is up-level (according to our proposal), 
everything works fine _unless_ there are nodes connected to both NN A and 
VRN A using the same TG numbers.

> TRH:  flow automatically, and the TDB is AOK again.

While it only takes one NN to support 8265 to detect the error and notify 
the operator, the damage is almost certainly already done before that one NN 
finds out about the duplicate names.  By the time the operator finds out 
about the problem he has to either

 -    disconnect the duplicate NN and rename it, or

 -    rename the VRN on every node connected to it.

The net is that the proposed solution results in a TDU war, unless the first 
node that learns about the duplicate names is up-level.  The alternate 
solution results in a TDU war unless the duplicate network node is up-level. 
 There doesn't seem much to choose between the proposals in a network with 
both up-level and down-level NNs!

> TRH:  the node name, hence the problem when duplicates exist.

This is just an internal implementation issue - nothing to do with the 
architecture.  There is nothing in the TRS chapter that specifies how the 
TDB is indexed.

As I pointed out above, there is little to choose from a migration 
standpoint between the the original proposal and what we are suggesting - 
ie. neither solution works seamlessly if not all NNs are upgraded. 
 Therefore, unless there is another approach which does migrate seamlessly, 
 we should be choosing the best long term solution.

It is utterly reasonable to allow NNs and VRNs to have the same name, since

 -    the architecture has obviously been designed to make sure that it is
     always possible to distinguish between an NN and a VRN (and it is 
therefore
     technically feasible)

 -    it otherwises appears to be a fairly arbitrary restriction to the 
average
     'dumb' user.

For the above reasons we strongly recommend the alternate solution we 
suggested is used as the basis for solving this problem.

 ----------------------------------------------------------------------------  
 ---------------------------------------
> TRH:      now all ENs are restricted, regardless of their name.

This is equivalent to a START_NODE parameter.

> TRH:      restricted except for those few that were allowed.

This is not supported by the proposal as it stands (the Delete's would fail 
because SS would not find a matching entry in the COS restriction list - see 
4th paragraph, page 5-39 of the update).

> TRH:      configured name as its CP name, otherwise the link won't come 
up.

This is true if the NN has all its links configured.  As previously 
discussed on this mail exploder, many (most?) NN implementations support 
'Implicit' links.

> TRH:  like to hear from those who do know.  Any comments?

AFTP does, ATELL, AFILE, AREXEC and APING do.  I suspect these applications 
are what many developers are using as models.  What do IBM recommend in 
their application development classes?

> TRH:  1) and 2) are also benefits that are obtained.

The proposal as it stands addresses 1) and 2), but really only scratches the 
surface of 3) (ie. there are enough easy ways to get around it, it becomes 
effectively worthless).  1) and 2) can be achieved with a much simpler 
change (both to implement, and to use) than that proposed (a START_NODE 
option).  We therefore recommend that the proposal is changed to use a 
START_NODE option rather than a new verb.  If DEFINE_CLIENT_RESTRICTION is 
required in the future, then it should be based on something more secure 
than CP names.